Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pip-control-msg-00.txt < prev next >

Wrap

Text File | 1993-06-16 | 26KB | 808 lines

Pip Working Group R. Govindan INTERNET-DRAFT P. Francis (formerly P. Tsuchiya) Bellcore June 1993 PCMP: Pip Control Message Protocol Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract Pip is an internet protocol intended as the replacement for IP version 4. This specification describes the packets used for various control purposes. Acknowledgements I would like to acknowledge Chris Petrilli for his initial work on this protocol. Conventions All functions in this specification are mandatory. Pip WG, Expires December, 1993 [Page 1] INTERNET-DRAFT PCMP June 1993 1. Introduction Pip is an internet protocol intended as the replacement for IP ver- sion 4. This specification describes the packets used for various control purposes, called Pip Control Message Protocol (PCMP). PCMP is Pip's analog to IP's ICMP. 2. Message Formats All PCMP messages are encapsulated in Pip headers. The value of the Protocol field when PCMP is used is 1. PCMP messages have the following format: +===========================+ | Fixed Part | +===========================+ | PCMP Body | +===========================+ The Fixed Part is formatted as follows: length, in bits +===========================+ | Type | 8 +---------------------------+ | Code | 8 +---------------------------+ | Checksum | 16 +===========================+ The Type field indicates the type of PCMP message. The meaning of the Code field depends on the PCMP message Type. The checksum is the 16-bit ones's complement of the one's complement sum of the PCMP mes- sage starting with the PCMP Type, and including the entire PCMP mes- sage. For computing the checksum, the checksum field is zero. 3. Transmitting a PCMP Message PCMP messages are transmitted in Pip headers. Because of Pip's Pip WG, Expires December, 1993 [Page 2] INTERNET-DRAFT PCMP June 1993 tunneling feature, PCMP messages are not always sent to the host that transmitted the original Pip packet to which the PCMP message is responding (as, for instance, ICMP messages are). Sometimes it is desirable to send a PCMP message to the originating host, and some- times to the entry system of a tunnel. In the latter case, the entry system may determine that the PCMP message should further go back to the source. For example, consider the case where the tunnel exit system is unreachable. A router within the tunnel will send the PCMP Packet Not Delivered to the tunnel entry system. If the tunnel entry system has another tunnel it can try, then it does not need to send the PCMP Packet Not Delivered further back. If the tunnel entry system has no other means of forwarding the packet, however, then it should forward the PCMP back to the source. Thus, a Pip system has two ways of forming a PCMP packet. One, the target of the PCMP packet is the originating host. Two, the target of the PCMP packet is the tunnel entry system. The target of the PCMP packet is determined by PCMP Type and Code. 3.1. Targeting the Originating Host When the target of the PCMP packet is the originating host, PCMP mes- sages are encapsulated in a Pip header as follows: 1. The Protocol field is set to PCMP. 2. An attempt is made to reverse each of the Transit Parts in the received Pip packet. (How to "reverse" a Pip Transit Part depends on the address family used, and is described in [4].) If any of the Transit Parts cannot be reversed, then the Pip header is formatted as though the target was the lowest tunnel entry system. (Note that, in the near-term Pip architecture, all routers will be able to reverse all Transit Parts.) 3. The Source ID field of the Pip header is set to be that of the sys- tem that originated the PCMP message. (If the PCMP message is being sent by a tunnel entry system as a result of receiving a PCMP message from a router in the tunnel, then the Source ID field is copied over from that of the received Pip header.) 4. The Dest ID field of the Pip header is set to that of the host that Pip WG, Expires December, 1993 [Page 3] INTERNET-DRAFT PCMP June 1993 originated the original Pip packet. (If the PCMP message is being sent by a tunnel entry system as a result of receiving a PCMP mes- sage from a router in the tunnel, then the Dest ID field is copied over from the Source ID field of the received Pip header which is stored in the Received Pip Header field of the PCMP message.) 3.2. Targeting the Tunnel Entry System When a PCMP packet is being returned to the tunnel entry system, the PCMP message is encapsulated in a Pip header as follows: 1. The Protocol field is set to PCMP. 2. The Source ID field of the Pip header is set to be that of the sys- tem sending the PCMP message. 3. The Dest ID field of the Pip header is set to the "any router" Pip ID value [1]. 4. Only the lowest Pip Transit Part is reversed. In addition, the lowest level FTIF of the tunnel entry system (now the target sys- tem) is modified to indicate that the packet should be received rather than forwarded. (How to make this modification depends on the address family used, and is described in the relevant specifi- cations. For hierarchical unicast Pip Addresses, the modification is described in [4].) This causes the tunnel entry system receiving the PCMP message to recognize that the packet is destined for it, and to send the packet to its PCMP module for processing (after checking the Dest ID field). 3.3. PCMP Message Processing by the Tunnel Entry System When a tunnel entry system receives a PCMP message, the message may be targeted to it either because 1) the PCMP Type and Code dictates that the tunnel entry system is the target, or 2) the originating host is the real target, but the sending system could not reverse all of the Transit Parts. In the former case, the tunnel entry system receives the PCMP message and processes it as a PCMP message. This may result in the tunnel Pip WG, Expires December, 1993 [Page 4] INTERNET-DRAFT PCMP June 1993 entry system originating a PCMP message of its own, possibly to the originating host. In this case, the Received Pip Header field remains the same as in the received PCMP message. The Pip Header of the received PCMP message is used to form the Pip Header of the transmitted PCMP message. The lowest Transit Part is stripped (this is the Transit Part that was reversed by the originator of the origi- nal PCMP message). The remaining Transit Parts need to be reversed. The tunnel entry system reverses the remaining Transit Parts accord- ing to the above rules for forming a PCMP message. In the latter case, the tunnel entry system does not process the PCMP message per se (though of course it must look at the Type and Code to determine if it should process the PCMP message or not). Instead, the tunnel entry system attempts to forward the packet to the ori- ginating host according to the rules above. 4. PCMP Messages 4.1. Type 101: Packet Not Delivered This PCMP message essentially replaces the ICMP Destination Unreach- able message. The PCMP body format of Packet Not Delivered is as follows: length, in bits +===========================+ | Information | 32 +---------------------------+ | Received Pip Header | variable +---------------------------+ | Original Datagram Data | 64 +===========================+ The contents of the Information field depends on the Code. Following is a description of the codes. 4.1.1. Code 1: Options Contents Unknown This PCMP Packet Not Delivered message is sent when the system does Pip WG, Expires December, 1993 [Page 5] INTERNET-DRAFT PCMP June 1993 not have a local mapping for the Options Contents field value. This PCMP message is sent to the originating host. The Information field is transmitted as zeros, and ignored upon receipt. 4.1.2. Code 2: Individual Option Unknown This code is sent when one or more of the options are unknown, and at least one of the options has handling type 5 (Discard Packet with Notification). The PCMP message is sent to the originating host. The Information field is formatted as follows: length, in bits +===========================+ | Unknown Options Bit Mask | 8 +---------------------------+ | zeros | 24 +===========================+ The Unknown Options Bit Mask indicates which options in the original packet are unknown (including those that do not require notification if unrecognized). The bits of the Unknown Options Bit Mask correspond to the bits of the Options Present field in the received Pip header. A 1 indicates that the option is unknown, and a 0 indi- cates that the option is either known or not present in the received packet. 4.1.3. Codes 3 and 4: Protocol These PCMP codes are sent when either the protocol indicated by the Protocol field of the received packet does not exist (code 3), or it exists but is administratively prohibited for the originating host (code 4). This PCMP message is sent to the originating host. The Information field is transmitted as zeros, and ignored upon receipt. 4.1.4. Codes 5 and 6: Port These PCMP codes are sent when either the TCP or UDP port of the received packet cannot receive the packet (code 5), or it can receive Pip WG, Expires December, 1993 [Page 6] INTERNET-DRAFT PCMP June 1993 the packet but is administratively prohibited for the originating host (code 6). This PCMP message is sent to the originating host. The Information field is transmitted as zeros, and ignored upon receipt. 4.1.5. Codes 7, 8, and 9: Dest ID These PCMP codes are sent by a Pip system X when the received packet can't be delivered to the Pip system Y indicated by the Dest ID. Code 7 is used when system Y is known not to exist within the domain of systems indicated by the Routing Directive. Code 8 is used when the originating host is administratively prohibited from sending packets to system Y. Code 9 is used otherwise. For example, if the Pip packet reaches the final router on the desti- nation subnetwork, and the router knows that the Dest ID does not exist on the subnetwork, then code 7 is used. If as far as the router knows the Dest ID could exist on the subnetwork but can't be reached (for instance, there is no response to ARP requests), then it would send Code 9. These PCMP messages are sent to the originating host. The Informa- tion field is transmitted as zeros, and ignored upon receipt. 4.1.6. Code 10: Hop Count Expired This PCMP code is sent when the Hop Count field is decremented to 0 by the forwarding router. (Hosts do not decrement the hop count field.) This PCMP message is sent to the originating host. The Information field is transmitted as zeros, and ignored upon receipt. 4.1.7. Code 11: HD Contents Unknown This PCMP Packet Not Delivered message is sent when the system does not have a local mapping for the HD Contents field value. The PCMP message is sent to the system identified by the source portion of the lowest Transit Part. The Information field is transmitted as zeros, and ignored upon receipt. Pip WG, Expires December, 1993 [Page 7] INTERNET-DRAFT PCMP June 1993 4.1.8. Code 12: Individual HD Parameter Unknown This code is sent when one or more of the parameters in the HD are unknown, and at least one of the parameters has handling type 5 (Dis- card Packet with Notification). The PCMP message is sent to the sys- tem identified by the source portion of the lowest Transit Part. The Information field is formatted as follows: length, in bits +===========================+ | Unknown HD Parameters Mask| 32 +===========================+ The Unknown HD Parameters Mask indicates which HD parameters in the original packet are unknown (including those that do not require notification if unrecognized). The bits of the Unknown HD Parameters Mask correspond to the bits of the HD field in the received Pip header. All 1's indicates that the parameter is unknown, and all 0's indicates that the parameter is known. The PCMP message is sent to the system identified by the source por- tion of the lowest Transit Part. The zeros field is transmitted as zeros, and ignored upon receipt. 4.1.9. Code 13: RC Contents Unknown This PCMP Packet Not Delivered message is sent when the system does not have a local mapping for the RC Contents field value. The PCMP message is sent to the system identified by the source portion of the lowest Transit Part. The Information field is transmitted as zeros, and ignored upon receipt. 4.1.10. Code 14: Individual RC Parameter Unknown This code is sent when one or more of the parameters in the RC are unknown, and at least one of the parameters has handling type 5 (Dis- card Packet with Notification). The PCMP message is sent to the sys- tem identified by the source portion of the lowest Transit Part. The Information field is formatted as follows: Pip WG, Expires December, 1993 [Page 8] INTERNET-DRAFT PCMP June 1993 length, in bits +===========================+ | Unknown RC Parameters Mask| 16 +---------------------------+ | zeros | 16 +===========================+ The Unknown RC Parameters Mask indicates which RC parameters in the original packet are unknown (including those that do not require notification if unrecognized). The bits of the Unknown RC Parameters Mask correspond to the bits of the RC field in the received Pip header. All 1's indicates that the parameter is unknown, and all 0's indicates that the parameter is known. The PCMP message is sent to the system identified by the source por- tion of the lowest Transit Part. The zeros field is transmitted as zeros, and ignored upon receipt. 4.1.11. Codes 15, 16, and 17: FTIF These PCMP Packet Not Delivered messages are sent when a packet can't be forwarded based on the contents of the active FTIF field. Code 15 is used when the Pip hosts represented by that FTIF are known not to exist. Code 16 is used when the originating host is administratively prohibited from sending packets to the systems represented by the FTIF. Code 17 is used otherwise. The Information field for these codes is formatted as follows: length, in bits +===========================+ | Active RC | 16 +---------------------------+ | zeros | 8 +---------------------------+ | Active FTIF Offset | 8 +===========================+ The purpose of the Active RC and Active FTIF Offset fields are to indicate which FTIF the PCMP message refers to, and the Routing Con- text associated with that FTIF. It is necessary to convey this Pip WG, Expires December, 1993 [Page 9] INTERNET-DRAFT PCMP June 1993 information separately (as opposed to using the corresponding fields in the Received Pip Header area) because the Routing Context and failed FTIF may not be those of the received Pip header. For instance, the Pip forwarding engine may have successfully parsed one or more FTIFs before reaching the failed FTIF. The routing context may also have changed, for instance because the hierarchical level may have changed. The PCMP message is sent to the system identified by the source por- tion of the lowest Transit Part. The zeros field is transmitted as zeros and ignored upon receipt. 4.1.12. Codes 18: Maximum Transmission Unit (MTU) Exceeded This PCMP message is sent when the router cannot transmit a Pip packet because the packet size exceeds the maximum deliverable by the transmitting interface. The Information field is formatted as follows: length, in bits +===========================+ | Next-Hop MTU | 32 +===========================+ The Next-Hop MTU field contains the size in octets of the largest datagram that could be forwarded, along the path of the original datagram, without being fragmented at this router. The size includes the Pip header and Pip payload, and does not include any lower-level headers. Because of tunneling, the received Pip header may be larger than that sent by the originating host. The originating host can compare the size of the received Pip header with that of what it sent (as indi- cated by the combined values of the Packet SubID, Protocol, Dest ID, and Source ID), and appropriately calculate the required payload size. This PCMP message is sent to the originating host. Pip WG, Expires December, 1993 [Page 10] INTERNET-DRAFT PCMP June 1993 4.2. Type 102: PCMP Echo PCMP Echo has two Codes. Code 0 is the PCMP Echo query, and Code 1 is the PCMP Echo reply. PCMP Echo replies are sent to the originat- ing host. When a PCMP Echo query is sent, the Dest ID field of the Pip header may contain either the ID of the system that the PCMP Echo is des- tined for, or it may contain the "Any System", "Any Host", or "Any Router" Pip IDs [1]. If a router receives a PCMP Echo query with either the Any System or Any Router Pip IDs, and, based on the con- tents of the Routing Directive, the router is not able to further forward the packet, then the router responds with a PCMP Echo reply. If a host receives a PCMP Echo query with the Any System or Any Host Pip IDs, then it responds with a PCMP Echo reply regardless of the RD. In both cases, the Source ID in the Pip header of the PCMP Echo reply contains the Pip ID of the transmitting router or host. The PCMP Body of the PCMP Echo message is formatted as follows: length, in bits +===========================+ | Identifier | 32 +---------------------------+ | Sequence Number | 32 +---------------------------+ | Data | Variable +===========================+ The Identifier, Sequence Number, and Data are returned in the PCMP Echo reply as received in the corresponding PCMP Echo query. 4.3. Type 103: PCMP Router Advertisement The PCMP Router Advertisement message is similar to the ICMP Router Advertisement message [2]. The body of the PCMP Router Advertisement message is formatted as follows. Pip WG, Expires December, 1993 [Page 11] INTERNET-DRAFT PCMP June 1993 length, in bits +===========================+ | Num Addrs | 16 +---------------------------+ | Lifetime | 16 +===========================+ | Length of address[1] | 16 +---------------------------+ | Preference Level[1] | 16 +===========================+ | Router Address[1] | variable number of 32 bit words +===========================+ | Length of address[2] | 16 +---------------------------+ | Preference Level[2] | 16 +===========================+ | Router Address[2] | variable number of 32 bit words +===========================+ | .... | The PCMP code value associated with this message is zero. Num Addrs is the number of router addresses advertised in this message and Lifetime is the maximum number of seconds that the advertised addresses can be considered valid. The "Length of address[i]" is the length in 32-bit words of the ith address advertised. "Preference Level[i]" indicates the preferability of the ith advertised address, as a default router address, relative to other router addresses on the same subnet; it is a signed, twos-complement number and higher values mean greater preferability. Each router address consists of a variable number of 32-bit words, each of which encodes a Pip address number. These words are ordered by increasing metalevel and level values of the Pip address numbers they encode. Each word contains the Pip address number in the lower 16-bits and a 1 in the upper 16- bits if the Pip address number is on a different metalevel from the preceding Pip address number. When a Router Advertisement is sent, the destination ID field in the Pip header contains the Pip ID of the host that the advertisement is directed towards or the "Any host" Pip ID [1]. If a host receives a Router Advertisement with the "Any Host" Pip ID, the host then uses the advertised addresses in a manner discussed in [3]. Pip WG, Expires December, 1993 [Page 12] INTERNET-DRAFT PCMP June 1993 4.4. Type 104: PCMP Router Solicitation The PCMP Router Solicitation message is similar to the ICMP Router Solicitation message [2]. The body of the PCMP Router Solicitation message is formatted as follows: length, in bits +===========================+ | Reserved | 32 +===========================+ The reserved field is sent as zero and ignored upon reception. The PCMP code value associated with this message is zero. When a Router Solicitation message is sent, the destination ID field in the Pip header contains the "Any Router" Pip ID [1]. If a router receives a Router Solicitation and the RD indicates that the router is an intended recipient, it may respond with a Router Advertisement. 4.5. Local Redirect To be supplied...... 4.6. Parameter Problem To be supplied...... 4.7. Router Discovery To be supplied...... 4.8. Provider Redirect To be supplied...... Pip WG, Expires December, 1993 [Page 13] INTERNET-DRAFT PCMP June 1993 4.9. Reformat Transit Part To be supplied...... 4.10. Host Mobility To be supplied...... 4.11. Exit PDN Address To be supplied...... References [1] P. Francis, "Pip Identifiers", Internet-draft [2] "ICMP Router Discovery Messages", S. Deering ed., RFC 1256. [3] "Pip System Discovery", to be written. [4] P. Francis, "Pip Address Conventions", Pip WG, Expires December, 1993 [Page 14]